The present invention is described with reference to the Internet, a global internetwork of networks in common usage today for a variety of applications, but it should be understood that references to the Internet can be substituted with references to variations of the basic concept of the Internet (e.g., intranets, virtual private networks, enclosed TCP/IP networks, etc.) as well as other forms of networks.
Generally, network nodes that connect to other network nodes support a variety of protocols as various network levels. At the application level, many Internet nodes support HyperText Transport Protocol (HTTP) for sending and receiving hypertext pages, which might include HyperText Markup Language (HTML) pages and other data supported by devices and software that handle HTTP messages. HTTP is a client-server protocol, in that a node that acts as an HTTP client makes requests of a node that acts as an HTTP server. When an HTTP client makes a request, the request includes a Universal Resource Locator (URL) that refers to the page or data requested. The URL comprises a globally unique domain name and possibly other fields that are specific to that domain name. Thus, any HTTP client can make a request by sending the request into the network. The network will resolve the domain name and route the request to an HTTP server at the specified domain and that HTTP server will resolve the remaining fields of the URL to determine what was requested.
When HTTP first came into common use, HTTP was a sessionless protocol in that a client making an HTTP request established a communication session with the HTTP server at a lower network layer, made the request, received the file and then the communication session was terminated and the client and the server did not track activity. Thus, if a server received a sequence of page requests from the same client, the server would not notice that they were from the same client, as the server had no way of tracking a “session” comprising multiple requests and responses.
In later versions of HTTP, the concept of “cookies” was added. Cookies are data elements that a server provides to a client with the expectation that the client will return the cookie in subsequent transactions, thus allowing the server to “remember” the client from request to request and thereby establish sessions and client “state” at the application layer. An example of a cookie-enabled HTTP system is shown in FIG. 1. There, a user system 10 is shown comprising a browser coupled to a network and a display coupled to the browser. The browser is shown comprising a page generator, an HTTP client and a cookie table. In operation, the HTTP client requests pages over the network, providing relevant cookies with the requests and stores received cookies. The page generator generates the requested page, sending requests for additional pages to the HTTP client as indicated by the page being generated for display. As is well-known in the art, an HTTP client might retrieve an HTML page that references other pages and in generating a display of that page, the HTTP client might make additional requests for additional pages referenced by the initial requested page.
In a typical session, a client sends a request to the server and the server returns a response to the request, along with a cookie that the server generates. The cookie is unique to that client, and possibly that session with that client. The client uses the response and stores the cookie along with an indication of the server that sent the cookie. Then, whenever the client makes a request to that server, the client includes with the request the cookie that the server provided. Since the server has associated that cookie with a particular client, the server can tailor its responses based on the client's state.
The ability to maintain client state at an HTTP server allowed content providers to provide content specific to the user of a particular client. For example, one widely used content provider is the Yahoo! network (based at www.yahoo.com). A computer user (or computing device or client device user) can access the content of the Yahoo! network by coupling a client to the Internet (or other equivalent network) and directing HTTP page requests to the Yahoo! servers. The user can operate in a stateless manner, wherein each page is served without reference to, and possibly without knowledge of, prior activity of that user. However, a more customized experience can be provided where the Yahoo! system maintains a state for the user. An example of this is the My Yahoo! property found at “my.yahoo.com”.
The Yahoo! system, as well as other stateful content systems, maintains a state for each registered user. The state might include personal data (e.g., name, e-mail address, street address, telephone number, etc.), demographic data (e.g., age, gender, preferences, interests, etc.) and network behavior (pages visited, interests as determined by common page views). If a user is identifiable, the system can provide a customized experience by, for example, showing only content known to be of interest to that user and advertising that would likely be of interest to that user.
FIG. 2 illustrates an arrangement of systems for browsing content with advertisements included. As shown there, a content provider system 12 is coupled to user system 10 and an advertising provider system 14 is coupled to user system 10. Typically, such coupling is via the Internet. Content provider system 12 is shown comprising a content server 20 coupled to the network, content storage 22 coupled to content server 20 and user profile storage 24 coupled to content server 20. Advertising provider system 14 is shown comprising an ad server 30, an ad reference server 32, ad views data storage 34, campaign data storage 36 and campaign generator 38.
In a typical operation, a user uses user system 10 to request a page of content. The request is a URL directed at content server 20. In response, content server 20 provides the requested page, which may include a reference to an advertisement maintained elsewhere (e.g., at advertisement server system 14). Typically, the user logs into content server 20 so as to identify the user with the content server. If the content server can identify the user, typically associating the user with a content provider assigned ID, the content server can access user profile storage 24 to provide customized content for that user and establish behaviors of that user (e.g., what pages visited and other observed preferences). The user profile might also contain user-volunteered demographic information.
In response to the advertisement reference, user system 10 will request an advertisement, such as a banner ad, from ad server 30. The particular advertisement requested is often determined by campaign generator 38, which provides campaign data to ad reference server 32, which in turn provides the reference to content server 20 so that content server 20 can provide it to user system 10. Ad server 30 serves up the ad that is requested and logs the page view in ad views data 34. At the end of a campaign, the results of the campaign, such as how many page views occurred and how many unique page views occurred, can be obtained by reviewing the ad views data 34.
Data is probably the most significant component of third party advertisement serving. With the right data and reports, decisions can be made to better run advertising campaigns and measure proper performance of campaigns. With the right reporting technology, this data can also help bridge the gap between online and offline reporting and ultimately media-buy. At present, agencies and advertisers must guess on the usefulness of a particular data source before they run their campaign on a disparate network, since there is typically no opportunity to shop for better or more comprehensive data after the campaign universe has been created.